Thanks! I agree that documenting char::is_lowercase as "Returns true if this char is lowercase" is silly.

I think this change is mostly fine but I would like to try to improve clarity of the all-important first sentence on each method. First sentences are supposed to stand alone to the extent that if you only read the first sentence of each method you still get a reasonable understanding of the point of the method. Documentation writers commonly get this wrong by having the first sentence summarize the rest of the documentation of the method; if the summary can only make sense after reading and understanding the rest of the documentation then the first sentence fails to stand alone.

My feeling is that many of these new first sentences only make sense if the reader already understands the point of the method.

For example you have:

Returns true if this char has the White_Space property.

This sentence means nothing until after the reader learns what "White_Space property" refers to by reading the rest of the documentation.

As I see it there are 2 key things that a first sentence would need to communicate to characterize this method:

1. You (as the reader) know roughly what is meant by the word "whitespace". This method involves that type of whitespace as you would expect; it isn't some jargon.
2. But the details are complicated and have something to do with Unicode.

I think the sentence as written isn't effective at communicating either of these things. We can try to brainstorm some alternatives; I feel that something more in this direction would work better:

Returns true if this is a whitespace character as classified by Unicode's White_Space property.

Another dimension to keep in mind about first sentences is that they ideally communicate the point of the method to the intended target audience for the method ¹ in terms that makes sense for that audience. The set of people who will want to call is_whitespace() is different and has different background knowledge compared to the set of people who will need to call something like is_grapheme_extended(), so there will tend to be differences in the character of the documentation as a result.

¹ Occasionally we extend this to include also the set of people who would be most likely mislead into thinking that they want to call a method they shouldn't, i.e. "this is probably not what you want"-style documentation, but this is uncommon.

Sounds good, “the Unicode ... property” works for me. "Code point" instead of "character" is fine too, will leave that up to you. I would lean toward "character" because the type's documentation introduces it as "The char type represents a single character" and talks about "code point" only to clarify what character means on a technical level. I don't think it would be a benefit in clarity to make that distinction again in all of these methods.

I think Unicode is important to mention by name in some form. I would not expect readers to deduce that "the White_Space property" by itself refers to some Unicode thing. Searching for White_Space property brings up information about CSS white-space before anything about Unicode.

“this char” is intentionally omitted. In documentation I typically recommend sticking to English words instead of code blocks where English is sufficiently concise and unambiguous, as in "returns true if ..." rather than "returns true if ...". Code blocks are formatted deliberately to disrupt the reader's flow with a context switch and are only worth using if that is called for.